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DIGITAL TELEVISION RECEIVER WITH APPLICATION 
PROGRAMMING INTERFACE FOR USER MANAGEMENT 



BACKGROUND OF THE INVENTION 

This application claims the benefit of U.S. 
5 Provisional Application No. 60/107,949, filed November 

12, 1998. 

The present invention provides an Application 
Programming Interface (API) for downloadable broadcast 
applications to manage/access user-related information 

10 on a Digital Television (DTV) Receiver/Terminal. 

A set- top terminal, also referred to as an 
Integrated Receiver-Decoder (IRD) or a subscriber 
terminal, is a device that receives and decodes 
television signals for presentation by a television. 

15 The signals can be delivered over a satellite, through 

a cable plant, or by means of terrestrial broadcast, 
for example. Various applications have been proposed, 
or are currently available, via modern set tops, 
including video on demand (VOD) , audio on demand, pay- 

20 per-view, interactive shopping, electronic commerce, 

electronic program guides, Internet browsers, mail 
services (e.g., text e-mail, voice mail, audio mail, 
and/or video mail) , telephony services, stock ticker, 
weather data, travel information, games, gambling, 

25 banking, shopping, voting, and others. Applications 

may also enable Internet connectivity and possibly 
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Internet -based telephony. The set top functionality is 
enabled through specialized hardware and software. 

The applications may be downloaded by terminals 
via a network, loaded locally (e.g., via a smart card), 
5 or installed at the time of manufacture, for example. 

Moreover, with the increasing integration of 
computer networks such as the Internet, telephony 
networks, and broadband distribution networks, many 
opportunities arise for providing new types of 
10 applications. 

To optimize the user's ability to access these 
applications, there is a need for user management at 
the terminals. In particular, it would be desirable to 
provide a user-management API that can be implemented 
15 in software independently of a terminal's hardware and 

operating system. 

The API should allow new users to be recognized, 
or old users to be deleted, as well as recognizing a 
current user of the terminal. The API should provide a 
20 profile of each user and maintain a record of 

permissions that have been granted to the users, e.g., 
for accessing applications such as pay-per-view, or 
enforcing rating guidelines for children. 

The API should maintain a record of user 
25 preferences, such as preferred language and rating 

ceilings, personal data such as age, address, zip code, 
account numbers, as well as system- wide preferences, 
such as favorite channels, language, etc. 

The API should also maintain a registry of 
3 0 applications, resources, preferences and users. An 

application may use/access a resource, which is usually 
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a device, function or a process on the receiver (e.g. 
tuner, modem, database, etc.) 

The API should be compatible with Java(tm), 
ActiveX (tm) or an equivalent type of component based 
5 object-oriented technology. 

The API should be compatible with Digital Audio 
Visual Council (DAVIC) , American Television Standards 
Committee (ATSC) T3/S17 Digital TV Application Software 
Environment (DASE) , Digital Video Broadcast (DVB) - 
10 Multi-Media Home Platform (MHP) and other related 

environments . 

The API should be compatible with any application 
at a terminal, regardless of how the application was 
received or installed (e.g., downloaded, resident, from 
15 smart card, etc.) 

The present invention provides a system having the 
above and other advantages . 
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SUMMARY OF THE INVENTION 

The present invention provides a software 
architecture a set -top television terminal. In 
particular, an Application Programming Interface (API) 
is provided for applications to manage/access user- 
related information on the terminal . 

A "user" is one who is watching the TV or using 
its other functions, e.g., E-mail, games, etc. 

The API includes a user software package that 
includes registry, profile, permissions, change cause, 
change event, and registry event functions. A 
preferences package includes a registry, names, rating, 
preferred language, change cause, change event and 
registry event functions. A registry package includes 
type, factory, change event, listener, user, 
preference, resource and application functions. 

The present invention provides a multi-user 
environment (user registry and user profile) , and a 
registry for preferences which can be associated with 
an individual user (user- specif ic) or be common to all 
users (system-wide) . A set of permissions is 
associated with each user, or at least with a default 
user, which represents anybody watching the TV. 

In a particular embodiment, a television set- top 
terminal includes a computer readable medium having 
computer program code means, and means for executing 
the computer program code means to implement an 
Application Programming Interface (API) . The API 
provides (a) a user registry of a plurality of users of 
the terminal, (b) a preferences registry of preferences 
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of the users, and (c) permission (s) for controlling the 
users 1 access to at least one application that is 
provided at the terminal. 

The API provides a security policy to allow only 
5 specified applications to access the preferences 

registry. The security policy may be user-controlled. 
Thus, some applications can, and some cannot, access 
the preferences based on a security policy. This means 
that the user may allow only specified trusted 
10 applications to access his/her credit card number but 

not others, for example. These applications may be 
specified shop-at-home channels or the like. 

The API disallows access to user preferences by an 
application that does not have the required 
15 permission (s) , 

The permission (s) may be associated with each user 
individually, or may be associated with a default user. 
A default user might be provided to indicate that the 
entire family is watching the television together, or 
20 to indicate a guest or unknown person. 

Additionally, the application generally is 
responsive to the user preferences. For example, if an 
application such as an Electronic Program Guide (EPG) 
accesses a language preference of a particular user, 
25 the application can automatically select the language 
for text when the service information (SI) is 
multilingual. An application that tunes to channels 
(audio/video or audio-only) may automatically select 
the appropriate audio language based on the user's 
30 language preference. 

As another example, an EPG application may access 
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favorite channel information of a user to prepare a 
custom made guide to the programs that are currently 
playing. Or, an application which enables targeted 
advertisements may access information regarding a 
5 user's location (ZIP code), gender, age, family status, 

and other personal information, such as pets, hobbies, 
etc . 

Additionally, e- commerce -type applications may 
need to look at user credit card numbers, permissions 
10 to do on-line purchases, and other related preferences. 

The permission may also provide, for example, a 
parental control/rating ceiling or permission to buy 
Impulse Pay Per View (IPPV) programs, or engage in e- 
commerce transactions (e.g., purchase goods or services 
15 via the television - home shopping) . 

The preferences include a ratings ceiling 
preference. 

Moreover, the user preferences may include system- 
wide or user-specific. 

2 0 The user registry can be used to register a new 

user of the terminal, identify a current user of the 
terminal, and remove a former user of the terminal. 

For example, when an application needs to switch 
between users, it may do it by identifying the user 
25 using a logon screen, by PIN codes or passwords, or 
even personalized smart cards, or voice control, for 
example. 

The permission (s) enable the users to access a 
resource/ invoke functions of the terminal. This refers 

3 0 to accessing either some physical resource on the 

receiver, such as a modem or a tuner, the smart card, 
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etc., or an application, such as e-mail, web browsing, 
e- commerce, etc. 

The resource may be, for example, a device, 
function or a process on the receiver, such as a tuner, 
modem, database, plug-in module, cable, software 
module, network interface card, persistent storage, TV 
screen space, memory, CPU, conditional access (CA) 
module, and so forth. 

The API also is adapted to define one or more new 
types of user preferences, and add the new types of 
user preferences to the preferences registry. The new 
user preferences can be defined by a base interface, 
Preference, which is an object that can be added or 
removed from the Pref erenceRegistry . This allows one 
to define new types of user preferences, e.g., by 
extending it the same way as the LanguagePref erence 
extends the base Preference. 

For example, the preferences may include specific 
types of programs (sports, drama, humor, action, etc.). 

The API also is adapted to associate the new types 
of user preferences with the users. 

The API may be independent of an operating system 
and hardware of the terminal. 

A corresponding method is also presented. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows package relationships and 
dependencies in accordance with the present invention. 

FIG. 2 illustrates a user class/interface diagram 
in accordance with the present invention. 

FIG. 3 illustrates a preferences class/interface 
diagram in accordance with the present invention. 

FIG. 4 illustrates a registry class/interface 
diagram in accordance with the present invention. 
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DETAILED DESCRIPTION OF THE INVENTION 

1 . INTRODUCTION 

The present invention provides an Application 
Programming Interface (API) for downloadable broadcast 
5 applications to manage/access user-related information 

on a Digital Television (DTV) Receiver. 

The invention comprises the following two API 
components: 1) User API; and 2) User Preferences API . 
They can be used together where each user has a 
10 set of user preferences associated with it, or 

separately where there is a system- level set of 
preferences without a user association. 

A Registry package is also described herein, which 
provides a generic mechanism for registry-type 
15 constructs. 

2. MODEL DESCRIPTION 

FIG. 1 illustrates an API package in accordance 
with the present invention, namely a User package 110, 
a Preferences package 120, and a Registry package 130. 

20 These packages are described in the following sections, 

in connection with FIGs 2-4. 

Note that portions of the disclosure were 
generated automatically from Rational Rose(tm) CASE 
tool, developed by Rational Software Corporation, USA. 

25 The figures use the Rational Rose (tm) depiction of the 

Unified Modeling Language (UML) , which is a language 
for specifying, constructing, visualizing, and 
documenting the artifacts of a software- intensive 
system. A class diagram represents the static 
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structure of a system, and shows a pattern of behaviors 
that the system exhibits. This is accomplished by 
showing the existence of classes and their 
relationships. Each class is represented by a box with 
three sections. The top section lists the class name. 
The middle section denotes a list of attributes, and 
the bottom section denotes a list of operations. 

A solid or dashed line between classes denotes an 
association or dependency. A white diamond tip denotes 
aggregation by reference, while a black diamond tip 
denotes aggregation by value. A triangular arrowhead 
denotes a restricted navigation, e.g., inheritance of 
operation but not of structure. 

Moreover, interfaces and classes begin with an 
uppercase letter, while methods begin with a lowercase 
letter. A class is a template that defines a data 
structure, method and function calls for an object. An 
interface defines a set of methods/function calls that 
can be manipulated by a class. The class provides the 
code for implementing an interface. 

2 . 1 User Package 

FIG. 2 illustrates a user class/interface diagram 
in accordance with the present invention. A main 
UserRegistry interface 210 is the access point for 
getting information about any user. One or more users 
can be associated with each terminal (e.g., DTV 
receiver, set-top box, IRD, TV-enabled PC, etc.") 
Existing users can be retrieved, new ones can be 
created, and the current active user can be set via the 
UserRegistry object 210. The user is represented by the 
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UserProfile object 22 0, which holds the user's name and 
the user's preferences. The preferences may be that 
the user prefers to view/use certain types of 
television programs (e.g., favorite channels) and/or 
applications, preferred audio language, personal data, 
such age, location (address/zip code) , credit card 
numbers, etc. The user can be authenticated by 
invoking the implementation-neutral method 
authenticate () , which may invoke the particular 
mechanism of authenticating a user, such as Personal 
Identification Number (PIN) codes, passwords, etc. 
Users are associated with permissions which are 
internally used to enforce a security policy. 
Therefore, new permissions can be granted to each user. 
The permissions are implementation-specific since they 
are internal to the terminal. 

2 • 2 Preferences Package 

FIG. 3 illustrates a preferences class/interface 
diagram in accordance with the present invention. 

The preference package 120 serves two primary 
purposes: to hold system-wide preferences and to hold 
user-specific preferences. 

A system-wide preference is anything that applies 
to all users. For example, English may be a system 
wide preferred language which applies to all user 
unless they override it with their own user-specific 
preference (e.g., Spanish). 

When the preference is used in the system-wide 
sense, the access to it is provided via the 
PreferenceRegistry 310 obtained from the 
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RegistryFactory 430 (FIG. 4) . The user-specific 
preferences can be obtained directly from the user 
(UserProfile 220) . 

Any new preferences or settings must derive from 
5 the abstract Preference interface 330, which provides 

the listener mechanism and access to the unique 
preference name. The derived class/interface can 
provide any methods, behavior and data structures 
needed to describe the specific preference or settings 
10 object. 

Each application can register as a listener (using 
the addPropertyChangeListener () method) to a specific 
preference and be notified via the propertyChange ( ) 
method it must implement. 

15 Properties are uniquely identified by their names. 

If an application tries to store a Property with a 
duplicate name, the Pref erenceAlreadyExists Exception 
390 will be thrown. If the application does not have 
enough privileges to perform any of the 

20 PreferenceRegistry 310 methods, the 

AccessDeniedException 3 85 will be thrown. 

PropertyChangeEvent 350 is defined in the standard 
Java packages (JDK 1.2). Also, the notations "from 
security" in class 3 85, and "from beans" refer to 

25 classes ("Security" and "Beans", respectively) that are 
defined in JDK 1.2. 

2.3 Registry Package 

FIG. 4 illustrates a registry class/interface 
diagram in accordance with the present invention. 
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The Registry package 130 provides a basic 
mechanism to construct a Registry object of any kind. 
The Registry interface 410 is a base interface which is 
extended by all specific Registries, such as the 
UserRegistry 210 or the Pref erenceRegistry 310. 

A RegistryListener interface 440 and a 
RegistryChangeEvent interface 250 are associated with 
this package. The listener interface 440 is used by 
any object that wants to be notified of any changes in 
the Registry 410. Changes are considered those that 
affect the Registry 410 itself (not necessarily the 
individual elements in the registry) , such as adding or 
removing elements to/ from the Registry. The 
RegistryChangeEvent 250 is an abstract class which is 
extended by the specific registry events. 

Since most of the API is defined in terms of Java 
Interfaces, the RegistryFactory 43 0 is a class that 
hides the actual object construction implementation. 

The notation "from util" in the EventObject class 
415 refers to a class "Util" that is defined in JDK 
1.2. 

The notation "from resource" in the 
ResourceRegistry interface 480 refers to a class 
"Resource" that is discussed in commonly-assigned PCT 
Patent Application No. PCT/US99/23358 , filed October 7, 
1999, and entitled "Application Programming Interface 
(API) For Accessing And Managing Resources In A Digital 
Television Receiver." 

The notation "from application" in the 
ApplicationRegistry interface 490 refers to a class 
"Application" that is discussed in commonly- as signed 
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PCT Patent Application No. PCT/US99/23721, filed 
October 7 , 1999, and entitled "Software Application 
Lifecycle And Management For Broadcast Applications." 

3. CLASS AND INTERFACE DESCRIPTION 

The following sections provide the details of each 
class, interface and its methods. 

3.1 User Package 

This package 110 provides classes and interfaces 
necessary for user management functions. 

3.1.1 UserRegistry 

UserRegistry interface 210 provides access to all 
users defined on the system. It is derived from 
Registry 130. 

Public Operations: 

createUser (name : String) : UserProfile 

This method will create a new user of the 
specified name. 

Public operations are those methods that may be 
called and used by other objects since they are visible 
outside of the object (e.g., class). In contrast, 
private operations are visible only to the class 
itself . 

getCurrentUser () : UserProfile 

This method returns the user who is currently 
registered as the active user. 
getUserNames () : String [] 

This method returns a list of all known users in 
the registry. 
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setCurrentUser (newUser : String) : UserProfile 

This method defines a new current user. The 
implementation may prompt the user for a password or 
some other method of authentication. 
5 getUser (name : String) : UserProfile 

This method returns a UserProfile object of the 
specified name. 

3.1.2 UserProfile 

This interface 22 0 represents a container of a 
10 single user information, such as settings and 

preferences, billing info, etc. it is derived from 
UserPermissions 230. 

Public Operations: 
getName () : String 
15 Returns the name of this user. 

getPreferences () : Pref erenceRegistry 
This method returns this user's 
Pref erenceRegistry. All operations performed on the 
returned list of preferences will be reflected in this 
20 UserProfile. 

authenticate () : boolean 

This method is called to authenticate a user. It 
invokes an implementation-specific mechanism for user 
authentication. It may use a user dialog to ask for a 
25 password or PIN, or other authentication mechanisms. 

Returns TRUE if authentication succeeded; FALSE 
otherwise. 

grantPermission (newPermission : String) : void 

This method is called to add a new permission to 
3 0 the user. See UserPermissions. 
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3.1.3 UserPermissions 

This interface 23 0 defines a list of user 
permissions that can be granted to a user. 
Public Attributes: 
5 ippv : String = "IPPV Purchase" 

RATING : String = "Rating Override" 

3.1.4 Us erRegis try Event 260 

Derived from RegistryChangeEvent 250. 
Public Operations: 
0 getUserName () : java. lang. String 

This method returns the User Name of the User that 
caused this event. 



3.1.5 UserChangeCause 

This interface 240 defines possible causes for the 
15 UserRegistryEvent 260. 

Public Attributes: 
USER_ADDED : short = 1 
US ER_REMOVED : short = 2 
NEW_CURRENT USER : short = 3 



20 3.2 Preferences Package 

This package 120 defines a set of interfaces and 
classes which provide a mechanism to define a set of 
preferences, either at the system level or at the user 
level . 
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3.2.1 



P r e f e r enc e Al r eadyExi s t s Exc ep t i on 
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This exception 3 90 signals that a preference of 
the same name is already present in the registry and 
cannot be inserted (added) again. It is derived from 
Exception, which is in the JDK 1.2 core Java packages - 
5 j ava . lang . Exception . 

3.2.2 Pref erenceRegistry 

This interface 310 represents a registry of all 
settings and preferences that can be shared by multiple 
applications. It is derived from Registry 130. 
10 Public Operations: 

getPreference (pref erenceName : String) : 
org . atsc . preferences . Preference 

This method returns the preference of the 
specified name, or null if the name is unknown to the 
15 registry. 

addPreference (aPreference : 
org . atsc .preferences . Preference) : void 

This method allows an application to insert a new 
preference object into the registry. The new 
20 preference must be of a unique name. 

removePreference (pref erenceName : String) : void 

This method allows an application to remove a 
preference object from the registry. 

listPref erences () : 
25 org . atsc .pref erences . Preference [] 

This method returns a list of all Preferences 
currently stored in the registry. 

3.2.3 Pref erredLanguage 



This interface 340 is an example of a language 
preference interface. An ordered list of ISO 63 9.2 
alpha-3 strings is used. The first language in the 
list is the most desirable language. It is derived 
5 from the Preference interface 330. 

Public Operations: 

getLanguage () : String [] 

This method returns an ordered list (most 
desirable first) of three letter ISO language codes. 
10 setLanguage (valueList : String []) : void 

This method allows an application to change the 
language preference. It returns the new list. 

3.2.4 RatingPref erence 

This interface 335 represents a parental rating 
15 preference based, e.g., on age. It is derived from the 
Preference interface 330. 

Public Operations: 

getRatingCeiling () : String 

This method returns the maximum rating value 
2 0 allowed for watching. 

setRatingCeiling (aValue : String) : String 

This method allows an application to change the 
rating ceiling. It returns the new rating level. 

3.2.5 Preference 

25 Thi s is a top-level interface 330 which is common 

for all preference/settings subinterf aces . It "supports 
the listener model and provides the preference name. 
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This interface can be extended to support specific 
preferences with specific access methods. It is 
derived from Pref erenceNames 320. 

Public Operations: 
5 addPropertyChangeListener (aListener : 

PropertyChangeListener) : void 

This method allows applications interested in 
changes to this preference to register for preference 
change events. 

10 removePropertyChangeListener (aListener : 

PropertyChangeListener) : void 

This method allows a preference change listener to 
remove itself from the list of listeners. 
getPref erenceName () : String 
15 This method returns a unique preference name. 

3.2.6 Pref erenceNames 

This interface 32 0 contains a list of predefined 
preference names. 

Public Attributes: 
20 SIMPLE_RATING : String = "Simple Rating" 

LANGUAGE : String = "Language" 

3.2.7 Pref erenceRegistryEvent 

This event 360 informs the RegistryListener 440 
about changes in the Pref erenceRegistry 310. It is 
25 derived from Regis tryChangeEvent 250. 
Public Operations: 

getPreference () : org. atsc. preferences. Preference 

Returns the preference that has changed in the 
repository. This change concerns the repository, such 
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as adding or removing a Preference from the 
PreferenceRegistry 310, not a change in the value of 
the Preference . 

3.2.8 Pref erenceChangeCause 

5 This interface 345 defines reasons for a 

Pref erenceRegistryEvent 360. 
Public Attributes: 
PREFERENCE_ADDED : short = 1 
PREFERENCE_REMOVED : short = 2 

10 3.3 Registry Package 

This package 13 0 provides a set of supporting and 
utility classes and interfaces used by other packages. 

3.3.1 Registry 

This interface 410 provides a common root to all 

15 specialized registry interfaces, such 

ApplicationRegistry 490, ResourceRegistry 480, 
PreferenceRegistry 310, etc. It is provided so that 
the RegistryFactory 43 0 can return a base type. 

A "base type" is known from the field of object - 

20 oriented programming. To illustrate, one can define a 
class with a set of functions (methods) and internal 
variables (e.g., a class "Fruit" which represents fruit 
and its basic characteristics) . One can specialize it 
by defining a new class, "Apple", which inherits 

25 everything from the class "Fruit", and adds new 

functions that are applicable only to Apples but not to 
Fruit in general. "Fruit" is then referred to as a 
"base class" or a "base type." 
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The Registry interface 410 is derived from 
RegistryType 405. 

Public Operations: 

getRegistryType () : String 
5 Called to determine the type of registry 

implemented by the object returned by the 
RegistryFatory's (430) method getRegistry () . 

addRegistryListener (listener: Regis try-Listener) : 

Called to register for events generated by the 
10 Registry 410. 

removeRegistryListener (listener : 
RegistryListener) : 

Called to de-register for events generated by the 
Registry 410. 

15 3. 3 .2 Regis tryFactory 

This class 43 0 provides a mechanism to create 
objects that implement specific Registry interfaces, 
such as the ApplicationRegistry 490. This class is 
modeled after the Factory Method design pattern, which, 

2 0 as is known from the field of object-oriented 

programming, is a methodology and structure for solving 
a problem. 

Public Operations: 

Regis tryFactory () : 
25 Constructor 

getRegistry (registryName : String) : 
org . atsc . registry . Registry 

Returns an instance of an object which implements 
the specified registry interface. Returns null when 

3 0 specified registry does not exist or cannot be created. 
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The type of the returned object will be one of the 
derived Registry types, such as the ApplicationRegistry 
490. 

3.3.3 RegistryType 

This interface 405 defines names for different 
registry types, such as an application registry, etc. 
Public Attributes: 

APPLICATION_REGISTRY : String = "Application 
Registry" 

RESOURCE__REGI STRY : String = "Resource Registry" 
PREFERENCE_REGISTRY : String = "Preference 
Registry" 

US ER_REGI S TRY : String = "User Registry" 

3.3.4 RegistryListener 

This interface 440 allows an object to listen to 
changes made to the Registry 410. 
Public Operations: 

regis tryChange () : ApplicationRegistryEvent 

This method of all registered 
ApplicationRegistryListeners is called by the 
ApplicationRegistry object 490 when an 
ApplicaionRegistryEvent is fired (emitted) . 

3.3.5 Regis tryChangeEvent 

This event 250 is a generic registry change event 
that is extended by all specific registries (such as 
ApplicationRegistry 4 90, etc.) to provide specific 
information about the change. It is derived from 
Event Object 415. 
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Public Operations: 

getRegistryType () : java.lang. String 

Returns the type of a registry that this event is 
associated with. 
S getCause () : short 

Returns the cause of the Regis tryChangeEvent 250. 
Each derived event will define a set of causes 
appropriate for the registry it represents. 

Accordingly, it can be seen that the present 

0 invention provides an API for applications to 

manage/access user-related information on a Digital 
Television (DTV) Receiver/Terminal. The API provides a 
mult i -user environment, and a registry for preferences 
which can be associated with an individual user or be 

5 common to all users. A set of permissions is 

associated with each user, or at least with a default 
user. The permission may provide, for example, a 
parental control/rating ceiling or permission to buy 
Impulse Pay Per View (IPPV) programs, or engage in e- 

0 commerce transactions (e.g., purchase goods or services 

via the television) . The invention also supports a 
mechanism where some applications can, and some cannot, 
access the preferences based on a security policy. 
This means that the user may allow only specified 

5 trusted applications to access his/her credit card 

number but not others, for example, for an e- commerce 
application. 

Although the invention has been described in 
connection with various specific embodiments, those 

D skilled in the art will appreciate that numerous 
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adaptations and modifications may be made thereto 
without departing from the spirit and scope of the 
invention as set forth in the claims. 

For example, while various syntax elements have 
been discussed herein, note that they are examples 
only, and any syntax may be used. 

Moreover, the invention is suitable for use with 
virtually any type of network, including cable or 
satellite television broadband communication networks, 
local area networks (LANs), metropolitan area networks 
(MANs) , wide area networks (WANs), internets, 
intranets, and the Internet, or combinations thereof. 

Additionally, known computer hardware, firmware 
and/or software techniques may be used to implement the 
invention. 
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What is claimed is: 

1. A television set- top terminal, comprising: 

a computer readable medium having computer program 
code means; and 

means for executing said computer program code 
means to implement an Application Programming Interface 
(API) for accessing user-related information at the 
terminal, wherein: 

the API provides: (a) a user registry of a 
plurality of users of the terminal, (b) a preferences 
registry of preferences of the users, and (c) 
permission (s) for controlling the users 1 access to at 
least one application that is provided at the terminal; 
and 

the API provides a security policy to allow only 
specified applications to access the preferences 
registry. 

2. The terminal of claim 1, wherein: 
the security policy is user-controlled, 

3. The terminal of claim 1, wherein: 

the permission (s) are associated with each user. 

4. A television set-top terminal, comprising: 

a computer readable medium having computer program 
code means; and 

means for executing said computer program code 
means to implement an Application Programming Interface 
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(API) for accessing user-related information at the 
terminal, wherein: 

the API provides: (a) a user registry of a 
plurality of users of the terminal, (b) a preferences 
registry of preferences of the users, and (c) 
permission (s) for controlling the users 1 access to at 
least one application that is provided at the terminal; 
and 

the permission (s) are associated with a default 

user. 

5. The terminal of claim 1, wherein: 

the at least one application is responsive to the 
user preferences. 

6. The terminal of claim 1, wherein: 

the permission (s) control the users' access to a 
plurality of applications that are provided at the 
terminal . 

7. A television set- top terminal, comprising: 

a computer readable medium having computer program 
code means; and 

means for executing said computer program code 
means to implement an Application Programming Interface 
(API) for accessing user-related information at the 
terminal , wherein : 

the API provides: (a) a user registry of a 
plurality of users of the terminal, (b) a preferences 
registry of preferences of the users, and (c) 
permission (s) for controlling the users 1 access to at 
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least one application that is provided at the terminal; 
and 

the preferences include a language preference. 

8. The terminal of claim 1, wherein: 
the preferences include a ratings ceiling 

preference . 

9. A television set-top terminal, comprising: 

a computer readable medium having computer program 
code means; and 

means for executing said computer program code 
means to implement an Application Programming Interface 
(API) for accessing user-related information at the 
terminal , wherein : 

the API provides: (a) a user registry of a 
plurality of users of the terminal, (b) a preferences 
registry of preferences of the users, and (c) 
permission (s) for controlling the users 1 access to at 
least one application that is provided at the terminal; 
and 

said user preferences include system-wide 
preferences . 

10. The terminal of claim 9, wherein: 
said user preferences include user-specific 

preferences that override said system-wide preferences. 

11. The terminal of claim 1, wherein: 

the user registry registers a new user of the 
terminal . 
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12. The terminal of claim 1, wherein: 

the user registry identifies a current user of the 
terminal . 

13. The terminal of claim 1, wherein: 

the user registry removes a former user of the 
terminal . 

14. The terminal of claim 1, wherein: 

the permission (s) enable the users to access a 
resource of the terminal. 

15. The terminal of claim 1, wherein: 

the API is adapted to define at least one new type 
of user preference, and add the new type of user 
preference to the preferences registry. 

16. The terminal of claim 16, wherein: 

the API is adapted to associate the new type of 
user preference with the users. 

17. The terminal of claim 1, wherein: 

the API disallows access to user preferences by an 
application that does not have the required 
permission (s) . 



18 . A method for implementing a software " 
architecture for a television set- top terminal, 
comprising the steps of: 
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providing a computer readable medium having 
computer program code means; and 

executing said computer program code means to 
implement an Application Programming Interface (API) to 
provide : 

(a) a user registry of a plurality of users of the 
terminal, (b) a preferences registry of preferences of 
the users, and (c) permission ( s ) for controlling the 
users' access to at least one application that is 
provided at the terminal wherein: 

the API provides a security policy to allow only 
specified applications to access the preferences 
registry. 
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ABSTRACT 



An Application Programming Interface (API) for 
applications to manage/access user-related information 
on a Digital Television (DTV) Receiver/Terminal. The 
API provides a multi-user environment (using user 
registry (210) and user profile (220) classes), and a 
registry for preferences (310) which can be associated 
with an individual user (user- specif ic) or be common to 
all users (system-wide) . A set of permissions (230) is 
associated with each user, or at least with a default 
user, which represents anybody watching the TV. The 
permission may provide, for example, a parental 
control/rating ceiling or permission to buy Impulse Pay 
Per View (ippv) programs, or engage in e-commerce 
transactions (e.g., purchase goods or services via the 
television) . The invention also supports a mechanism 
(220) where some applications can, and some cannot, 
access the preferences based on a security policy. 
This means that the user may allow only specified 
trusted applications to access his/her credit card 
number but not others, for example, for an e-commerce 
application. 
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